Skip to content

Conversation

@octo-sts
Copy link
Contributor

@octo-sts octo-sts bot commented Jul 1, 2025

@octo-sts octo-sts bot added P1 This label indicates our scanning found High, Medium or Low CVEs for these packages. automated pr maven/pombump request-cve-remediation solr GHSA-g93m-8x6h-g5gv labels Jul 1, 2025
@octo-sts
Copy link
Contributor Author

octo-sts bot commented Jul 1, 2025

⚙️ Build Failed: Configuration

Error: failed to parse the pom file: open pom.xml: no such file or directory

Build Details

Category Details
Build System Maven
Failure Point maven/pombump step

Root Cause Analysis 🔍

The build process is looking for a pom.xml file that doesn't exist in the expected location. This suggests a configuration issue with the build pipeline for Solr, as it's attempting to use Maven/pombump on a repository structure that either doesn't use Maven as its primary build system or has its pom.xml located in a different directory.


🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Similar PRs with fixes

Suggested Changes

File: solr.yaml

  • remove at line 31-32 (pipeline section)
    Original:
  - uses: maven/pombump
Click to expand fix analysis

Analysis

The common pattern observed in similar fixed build failures is that the maven/pombump step is failing because it can't find a pom.xml file. This typically happens when a project doesn't use Maven as its primary build system. In the fixed examples:

  1. For Cassandra, which uses Ant build system, the fix was to specify the location of a pom file using the "pom" parameter.
  2. For Selenium, which uses Bazel build system, the fix was to remove the maven/pombump step entirely and use patching to handle dependency updates.

In the current Solr build failure, the issue is similar - Solr uses Gradle as its primary build system, not Maven, so there's no pom.xml file at the repository root where maven/pombump is looking for it.

Click to expand fix explanation

Explanation

The fix involves removing the maven/pombump step entirely from the pipeline since Solr uses Gradle as its build system, not Maven. This is evident from the build steps that follow the pombump step, which use Gradle commands like ./gradlew --write-locks and ./gradlew assembleDist.

Removing the maven/pombump step is appropriate because:

  1. Solr is primarily built with Gradle, which is confirmed by the presence of Gradle build files and the usage of ./gradlew commands in the build pipeline.
  2. The manual version updates for dependencies are already being handled directly in the pipeline by editing the versions.props file with sed commands.
  3. The build system successfully runs the Gradle commands after the pombump step fails, indicating that Gradle is the correct build tool for this project.

Unlike the Cassandra example where they specified a pom file location, there doesn't appear to be a need to use Maven at all for the Solr build. The Gradle system handles all the dependency resolution and building tasks.

Click to expand alternative approaches

Alternative Approaches

  • Instead of removing the maven/pombump step, we could add a 'pom' parameter to point to a specific pom.xml file if one exists somewhere in the Solr repository structure, similar to the Cassandra fix.
  • If maven/pombump is still needed for some reason, we could create a minimal pom.xml file as part of the build process before running the maven/pombump step.

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

@octo-sts octo-sts bot added the ai/skip-comment Stop AI from commenting on PR label Jul 1, 2025
@efbar efbar self-assigned this Jul 3, 2025
efbar added 3 commits July 3, 2025 11:19
Signed-off-by: Francesco Bartolini <francesco.bartolini@chainguard.dev>
Signed-off-by: Francesco Bartolini <francesco.bartolini@chainguard.dev>
Signed-off-by: Francesco Bartolini <francesco.bartolini@chainguard.dev>
@octo-sts octo-sts bot added the bincapz/pass bincapz/pass Bincapz (aka. malcontent) scan didn't detect any CRITICALs on the scanned packages. label Jul 3, 2025
Signed-off-by: Francesco Bartolini <francesco.bartolini@chainguard.dev>
@dnegreira dnegreira merged commit 0f1edb2 into main Jul 3, 2025
24 of 25 checks passed
@dnegreira dnegreira deleted the cve-solr-9.8.1-r0-8ce40f5bce534ff6c894ef8385ea3549 branch July 3, 2025 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ai/skip-comment Stop AI from commenting on PR automated pr bincapz/pass bincapz/pass Bincapz (aka. malcontent) scan didn't detect any CRITICALs on the scanned packages. GHSA-g93m-8x6h-g5gv manual/review-needed maven/pombump P1 This label indicates our scanning found High, Medium or Low CVEs for these packages. request-cve-remediation solr

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants